RHEL6.6のAMIでEBSを使用する際の注意点
森永です。
弊社はAmazon Linuxでサーバを構築することが多いのですが、たまにRHELを使うことがあります。
RHEL6.6のAMIを使った際にハマったのでまとめておきます。
現象
RHEL6.6のAMI（ID：ami-a15666a0）からインスタンスを立ち上げてRootボリュームの容量を確認したところ、100GのEBSをマウントしているにもかかわらず6Gほどしか認識していないことが判明しました。
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 5.8G 1.9G 3.6G 35% / tmpfs 1.8G 0 1.8G 0% /dev/shm
ちなみに、RHEL6.6以外のAMIではこの現象は起きませんでした。。。（RHEL6.5や7では問題なし）
原因
デフォルトのRootボリューム容量が6Gで、cloud-initで自動拡張が動いてくれないことが原因のようです。 lsblkコマンドで確認したところ、6Gの大きさでパーテーションが切られていました。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 100G 0 disk └─xvda1 202:1 0 6G 0 part
対処方法
パーテーションの切られ方がおかしいため、resize2fsコマンドを実行するだけでは解決できません。
gdiskを使ってパーテーションを拡張してから、ファイルシステム拡張という流れになります。
作業インスタンスへのアタッチ
そのままのインスタンスでの作業は怖すぎるので、作業用インスタンスを使用することにします。
まず、該当のRHELのインスタンスをStopし、EBSボリュームを取り外します。
この際、大量のEBSボリュームを抱えている場合、対象ボリュームを探すのに一苦労すると思いますので、インスタンス詳細画面から飛ぶことをおすすめします。
また、EBSのNameにインスタンス名などをつけておくと管理が楽です。（デタッチするとどのインスタンスにアタッチされていたかの情報がなくなるため）
EBSボリュームのStatusが「Available」になったら作業用インスタンスにアタッチします。
作業用インスタンスはAmazon Linuxの最小設定で作成すれば事足ります。
ただし、必ず作業用インスタンスはEBSボリュームと同じAZに配置するようにして下さい。（別AZだとアタッチできません。。。）
アタッチの設定はデフォルトのもので構いません。
パーテーションの拡張
この作業ではデータが破損、削除される可能性がありますので、既にボリュームを使用している場合にはSnapshotを取得しておきましょう。（新規インスタンスの場合は必要ありません。）
パーテーションの拡張をするのには、gdiskコマンドを使用します。
Amazon Linuxにはデフォルトでgdiskが入っています。（2015.03現在）
まず、拡張するボリュームを確認するために、lsblkコマンドを実行します。
今回の場合は"/dev/xvdf"が対象のボリュームとなります。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk └─xvda1 202:1 0 8G 0 part / xvdf 202:80 0 100G 0 disk └─xvdf1 202:81 0 6G 0 part
上記手順で確認したパスを引数にgdiskコマンドを起動します。
$ sudo gdisk /dev/xvdf GPT fdisk (gdisk) version 0.8.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT.
pコマンドを実行し、パーテーションの情報を表示します。 Disk identifier (GUID)とCodeをメモしておきます。
Command (? for help): p Disk /dev/xvdf: 209715200 sectors, 100.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): C0E76C1A-B601-48A7-A1E0-CC49DEFF6CB4 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 20971486 Partitions will be aligned on 2048-sector boundaries Total free space is 8388541 sectors (4.0 GiB) Number Start (sector) End (sector) Size Code Name 1 2048 12584959 6.0 GiB EF00
空のパーテーションを作成するために、oコマンドを実行します。
Command (? for help): o This option deletes all partitions and creates a new protective MBR. Proceed? (Y/N): Y
nコマンドを使用して、パーテーションの設定をします。
今回はボリューム全体を一つのパーテーションとして設定するため、ほぼデフォルトで設定しました。
「Hex code or GUID」の項目については、さきほどメモしておいたCodeの値を使用します。
Command (? for help): n
Partition number (1-128, default 1):
First sector (34-209715166, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-209715166, default = 209715166) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): EF00
Changed type of partition to 'EFI System'
xコマンドでエキスパートコマンドモードに変更してから、gコマンドで識別子を書き換えます。 識別子はさきほどメモしておいたDisk identifier (GUID)を使用します。
Command (? for help): x
Expert command (? for help): g
Enter the disk's unique GUID ('R' to randomize): C0E76C1A-B601-48A7-A1E0-CC49DEFF6CB4
The new disk GUID is C0E76C1A-B601-48A7-A1E0-CC49DEFF6CB4
最後に、wコマンドで設定をデバイスに書き込みます。 "The operation has completed successfully."が表示されたら完了です。
Expert command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): Y OK; writing new GUID partition table (GPT) to /dev/xvdf. The operation has completed successfully.
パーテーションの拡張は以上ですが、e2fsckコマンドを使用してエラーがないことを確認しておきましょう。
特にエラーが出力されなければ問題ありません。
$ sudo e2fsck -f /dev/xvdf1 e2fsck 1.42.12 (29-Aug-2014) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/xvdf1: 56645/393216 files (0.1% non-contiguous), 557393/1572864 blocks
ファイルシステムの拡張
ここでようやくresize2fsコマンドを使用できます。
元のインスタンスに戻してからでも出来るのですが、どうせなら作業用インスタンスでやってしまいましょう。
$ sudo resize2fs /dev/xvdf1 resize2fs 1.42.12 (29-Aug-2014) Resizing the filesystem on /dev/xvdf1 to 26214139 (4k) blocks. The filesystem on /dev/xvdf1 is now 26214139 (4k) blocks long.
元インスタンスへのアタッチ
マネジメントコンソールへ戻り、作業用インスタンスからEBSボリュームをデタッチします。
デタッチしたボリュームを元のインスタンスに再度アタッチします。
この時、Rootボリュームとしてアタッチする必要が有るため、Deviceのパスは"/dev/sda1"として下さい。
最後に確認としてRHELのインスタンスでdfコマンドを実行してみます。
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 99G 2.0G 92G 3% / tmpfs 1.8G 0 1.8G 0% /dev/shm
Great!!!
正しく100Gのボリュームとして認識されました！
まとめ
RHELは7が出たとはいえ、6が使われる機会がまだたくさんあると思います。
今回は対策としてRootボリュームのパーテーションを拡張して使用する方法をご紹介しましたが、本来であればRootボリュームを大きくせずにデータボリュームを作成して別にアタッチするという方法で対応したほうがよいでしょう。
そもそものcloud-initがおかしい訳なので、それを修正するのが筋かも。。。
